I don't have a scope to test, but are you sure that this will work. In the default case, the number of sample is data_stop-data_start + 1, I would expect it to be self.get_horizontal_record_length() in the other situation, not self.get_horizontal_record_length() - data_start + 1
I would write something like

start = self.data_start - 1
stop = np.min(self.data_stop, start + self.get_horizontal_record_length())
X_axis = self.x_0 + np.arange(start, stop)*self.delta_x

Thank you for reviewing my suggestion @clade. According to my experience with DPO2024B and DPO4104 oscilloscopes, the returned waveform is shorter than the record length when DATa:STARt is greater than 1. Since I have a DPO2024B at hand, I tested this using the simple script

import matplotlib.pyplot as plt
from PyTektronixScope import TektronixScope
scope = TektronixScope()
fig, ax = plt.subplots()
ax.set(xlabel='time / s', ylabel='voltage / V')
for start in (1, 10):
    print(f'Data start {start}\n##########')
    scope.set_data_start(start)
    for rl in (100000, 1000000):
        print(f'Record length {rl}\n#####')
        scope.set_horizontal_record_length(rl)
        time, voltage = scope.read_data_one_channel('CH1', x_axis_out=True)
        print(f'Received {time.size} data points for the time axis and '
              f'{voltage.size} data points for the voltage signal.')
        ax.plot(time, voltage, label=f'Data start {start}, record length {rl}')
ax.legend()
fig.tight_layout()

When using my suggestion

X_axis = (self.x_0 +
                  np.arange(self.data_start-1,
                            min((self.data_stop,
                                  self.get_horizontal_record_length()))) *
                  self.delta_x)

for constructing the x axis, this test normally* worked without any problems, with the command line output being

USB0::0x0699::0x03A3::C011644::INSTR has been automatically selected.
Data start 1
##########
Record length 100000
#####
Received 125000 data points for the time axis and 125000 data points for the voltage signal.
Record length 1000000
#####
Received 1000000 data points for the time axis and 1000000 data points for the voltage signal.
Data start 10
##########
Record length 100000
#####
Received 124991 data points for the time axis and 124991 data points for the voltage signal.
Record length 1000000
#####
Received 999991 data points for the time axis and 999991 data points for the voltage signal.

The DPO/MSO2000/B series distinguishes between a nominal and an actual record length. According to the manual, receiving 125000 datapoints at a nominal record length of 100000 is a normal behavior. Due to the equal length of time and value axis, the data was also plotted without any problem

Your version for constructing the time axis

start = self.data_start - 1
stop = np.min((self.data_stop, start + self.get_horizontal_record_length()))
X_axis = self.x_0 + np.arange(start, stop)*self.delta_x

(slightly modified so that np.min receives a tuple as one argument instead of two arguments, otherwise this line wouldn't work) worked equally well when the first data point is 1, but not when self.data_start is higher; 10 in my example. Then, the time axis and the waveform have different lengths, so that the output of my test script is

USB0::0x0699::0x03A3::C011644::INSTR has been automatically selected.
Data start 1
##########
Record length 100000
#####
Received 125000 data points for the time axis and 125000 data points for the voltage signal.
Record length 1000000
#####
Received 1000000 data points for the time axis and 1000000 data points for the voltage signal.
Data start 10
##########
Record length 100000
#####
Received 125000 data points for the time axis and 124991 data points for the voltage signal.

until it throws a ValueError on line 21, because the plot does not work when X and Y axis have a different length.

As a conclusion, I would still prefer my version, although I have to admit that the test I just described is the only one I did.

*My test normally worked using the construction of the time axis I suggested, but I tried it several times and in rare cases, there were different anomalies in the data that appeared to me like synchronizations problems, i.e. as if we would need to query *OPC? or *BUSY? after or before a certain command to reliably obtain the intended behavior. I think this is unrelated to the issue at hand. I will try to narrow that down further as soon as I find the time for that.

I have now finally found the opportunity to take another look at the synchronization problems I encountered in the test described above. They were simply due to the fact that I did not wait for a moment after calling set_horizontal_record_length, but instead called read_channel immediately.

It takes a moment for HORizontal:RECOrdlength to finish executing in the oscilloscope. In the meantime, my example already queries WFMInpre:XINcr, i.e. the sampling interval. This changes with record length, and without synchronization the returned value may or may not be the changed one.

It is somewhat surprising that HORizontal:RECOrdlength does not generate an OPC and therefore synchronization via *WAI, BUSY? or *OPC? is not possible. But that's another story, in any case my test shows that the time axis is constructed correctly with

X_axis = (self.x_0 +
                  np.arange(self.data_start-1,
                            min((self.data_stop,
                                  self.get_horizontal_record_length()))) *
                  self.delta_x)

but with

start = self.data_start - 1
stop = np.min((self.data_stop, start + self.get_horizontal_record_length()))
X_axis = self.x_0 + np.arange(start, stop)*self.delta_x

it is not for DATa:STARt > 1.